AKIBA.AWS 第5回 ネットワーク基礎編でAWS Media Servicesを使った社内向け動画配信テストをしてみた #akibaaws
はじめに
清水です。先日行われました弊社主催のAWSをテーマにした勉強会「AKIBA.AWS 第5回 ネットワーク基礎編」にて、AWS Media Servicesをつかった社内向けの動画配信テストをしてみました。本エントリでは今回の社内向け動画配信テストでどのような構成、仕組みを使ったか、以前AWS Media Servicesのリリース直後に行った配信テストとも比較しながら、まとめてみたいと思います。
なお、前回の配信を行った際のエントリは以下になります。
今回のAWS Media Servicesを使った動画配信テストの構成
今回は以下のような構成となりました。
構成のポイントを以下にまとめます。
- MacBook Proから配信
- 配信ソフトウェアはOBS Stuidoを利用
- カメラ、マイクは外付けUSB接続のものを利用
- インターネット回線は社内のWiFiを利用
- 映像をRTMPでAWS Elemental MediaLiveで受ける
- 東京リージョンのMediaLiveを利用
- Outputは配信用のHLSと、Archive用の2種類を用意
- それぞれのOutputでABR(Adaptive Bitrate)を考慮した設定
- MediaLiveから配信用HLSをAWS MediaStoreに出力
- 東京リージョンのMediaStoreを利用
- MediaStoreのからCloudFrontを経由して、エンドユーザにHLS形式で配信
- エンドユーザには視聴用のHTMLページを用意し、Video.jsのPlayerで視聴させる
- HLS形式にネイティブ再生対応していないChromeなどのブラウザでも視聴可能
配信ハードとソフトウェアについて
前回のAKIBA.aws 第3回での配信ではiPad mini（第2世代）のカメラ、マイクを使い、配信ソフトウェアはiOS向けのRTMP Streamerというアプリを使用しました。画質、音質はそれなりに良かったのですが、iPad miniでの配信になるため、カメラやマイクの配置、アングルが制限される、といった懸念事項がありました。
今回、カメラ、マイクは配置などがiPadよりも自由になるUSB接続のものを用意しました。またこのため配信ソフトウェアもiOS向けのものではなく、Mac（PC）から配信することを考えました。そこで使用した配信ソフトウェアがOBS Studioとなります。
OBS StudioではRTMPでカスタムストリーミングサーバーへ配信する設定とし、URLにMediaLiveのInputを設定します。MediaLiveへの配信解像度、ビットレートは1280x720, 5Mbpsとしました。（当初、1920x1080, 5Mbpsとしようとしていたいのですが、後述する問題のため1280x720としました。）
AWS Media Servicesを東京リージョンで利用
前回の配信の際にはリリース直後で、AWS Media Servicesのうちいくつかのサービスについては、まだ東京に来ていませんでした。これにはライブ配信の際に利用するMediaLive、MediaPackage、MediaStoreも該当します。その後、2018年2月上旬に東京リージョ ンでMedia五兄弟すべてのサービスが使えるようになりました。そのため今回の配信では、東京リージョンのMedia Services（具体的にはMediaLiveとMediaStore）を利用しています。
MediaLiveとMediaStoreを連携させてHLS形式で配信
前回の配信の際にはMediaLiveとMediaPackageを連携させて配信を行いました。MediaPackageではHLS形式でMediaLiveから映像を受け、mepg-DASH形式などに変換して多様な環境への配信に対応させることもできます。今回の配信では、MediaLiveから映像をMediaStoreで受け、そのままのファイルとして（MediaLiveが生成したHLS形式のまま）配信する方法を試してみました。この場合、エンドユーザへの配信はHLS形式のみとなりますが、後述しますVideo.jsを利用することで多様な環境での再生にも対応しました。
ライブ配信を行いながら同時に映像をアーカイブ
AWS Elemental MediaLiveではArchiveに設定したOutputを選択することにより、ライブ配信を別Output設定で行いながら同時に、Archive用の動画ファイルを生成することができます。今回この機能を使用して、S3にアーカイブを保存しました。
ABR(Adaptive Bitrate)を考慮したMediaLiveのOutputの設定
MediaLiveのOutput設定はChannel templateを使用することもできますが、今回はChannel templateを参考に独自に解像度、ビットレートを決め、以下としてみました。
- HLS出力のoutput
- 1920x1080, 5Mbps
- 1280x720, 3Mbps
- 640x360, 1Mbps
- アーカイブ用出力のoutput
- 1920x1080, 5Mbps
- 640x360, 1Mbps
配信ソフトウェアであるOBS Studioからは1280x720, 5Mbpsで配信しているので、一番良い画質の解像度が1920x1080であるのはあまり適切ではないですね… 後述しますが、当初はOBS Studioからも1920x1080, 5Mbpsで伝送しようと考えていたため、このようなABR設定となりました。
アーカイブ出力用については、高ビットレートのみを出力して後からトランスコードして画質を下げる、ということも考えました。しかしその場合、トランスコードの時間が別途発生してしまうと考え、ライブ配信と同時に2つの解像度、ビットレートでの保存を行いました。
Video.jsを用いた各種ブラウザでのHLS再生
前回の配信の際にはHLSのマニフェストファイル（拡張子.m3u8）へのURLを視聴者に参照してもらうかたちをとりました。この場合、SafariなどHLSにネイティブ対応しているブラウザ環境でのみ、再生が行えました。そのため例えばPC（Win/Mac）上のChromeでは再生できない、ということになります。このHLSにネイティブ対応していないブラウザでもHLSを再生するための1つの方法としては、今回使用したVideo.jsのようなJavaScriptで実装されているPlayerをHTMLページに埋め込むかたちが取られます。
今回はVideo.jsのvideojs-contrib-hlsというライブラリを使って、各種ブラウザからHLSの1ソースで配信を行いました。
ライブ配信時の様子やトラブルシュートなど
現場の機材編
まず配信ソフトウェアが稼働しているMacBook Pro (Retina, 13-inch, Early 2015)です。登壇者の近く、つまり参加者側ではなくスクリーン側に配置しました。後述しますがOBS Studioが予想以上にCPUを使用し、本番中MacBook Proのファンがフル回転していました。近くにいた参加者の方には騒々しくなってしまい申し訳ありませんでした。
続いてカメラです。社内でオンラインミーティングする際に使用するWebカメラを使用しました。（青く光っているほうが今回の動画配信テストに使用したもの。光っていないほうは社内録画用に別途配置していたものです。）USBカメラなので本番前に、最適な位置をフレキシブルに決めることができました。
そしてマイクです。これも社内でオンラインミーティングする際に使用するUSB接続のマイクを使用しました。MacBook Proとは反対側、登壇者よりに配置してなるべくクリアに登壇者の音声を拾えるようにしてみました。
配信の様子
実際の配信はこちらのような具合で視聴できました。こちらはGoogle Chromeでの視聴例になります。（Google ChromeでHLSでのライブ配信ができていることが今回の構成の一つの利点ですね。）
今回、Google Chromeの他、社内の方からAndroidタブレット上のFirefox、MacのSafari、WindowsのEdgeなど多様なデバイス、ブラウザで視聴できていた、とご連絡をいただきました。また日本の他、ヨーロッパ圏からも問題なく視聴できたというご連絡もいただきました。（これはブラウザというより、CloudFrontを使っている構成での利点となりますが。）みなさま、いつもありがとうございます。
ライブ配信時に起こった問題点とその際に取ることができたトラブルシュート
さて今回のテスト配信ですが、1つ事前の検証不足などのためトラブルが起きていました。トラブルの症状としては(1)視聴している複数の端末（含むヨーロッパ）でほぼ同じタイミングで映像が瞬断する。これは社内チャットでのコメントで確認できました。(2)視聴している映像の色味が突然変わってしまう。こちらも社内チャットから、ほぼ同じタイミングから視聴している端末のすべてで発生しているようでした。具体的には下記のような色味になってしまいました…
(1)の映像の瞬断については、視聴している端末側の問題ということでも発生しうるかと思います。しかし、複数で同時に発生しているとなると、配信ソフトウェアからAWS上で処理している経路のいずれかで問題が発生している可能性が高いです。(2)についても同じくですね。
実は今回、配信の本番前のOBS Studioの検証が不十分で、CPU使用率が高いまま（おおよそ70%前後）本番を迎えていた、という事情がありました。これも、当初はOBS Stuidoでの解像度を1920x1080で行おうとしていたのですが、CPU使用率が高く、解像度を下げれば少しましになるだろうということで1280x720にしていたのですが… これでもまだCPU稼働率は高いままだったようです。
(1)の問題が起きた前後ではCloudWatchメトリクスなどからNetwork inならびにinput video frame rateで一時的な値の下降が見られました。(2)の問題が起きた後、休憩時間でMacBook Pro上のOBS Stuidoの様子を見てみると（セッション中は見に行けない状況でした）、以下のようにOBS Studio上でドロップフレームが高頻度（1%以上）で発生していたことがわかります。CPU使用率も高い状態ですね。
映像の色味がかわる(2)の問題は一度配信ソフトウェアで停止→開始の対応をすることでリカバリーできました。が、(1)の画面が瞬断する状況はそれ移行も数回起き、やはりこのOBS Studioが稼働する際のパフォーマンスの問題かと考えています。
ライブ配信時のモニタリングの様子
今回のライブ配信中のMediaLiveのモニタリングの様子をまとめておきます。Network InとInput Video Frame Rateが下降したタイミングが何回かあることがわかりますね。
まとめ
AKIBA.AWS 第5回 ネットワーク基礎編にて行ったAWS Media Servicesを使った社内向け動画配信テストについてまとめてみました。AWS Elemental MediaLive + AWS Elemental MediaStore + Amazon CloudFrontを使ったHLS配信を行えたこと、またHLS形式1ソースにしながらVideo.jsを使うことでマルチデバイス、マルチブラザでの再生に対応するなど様々な収穫がありました。しかしOBS Stuido使用での高負荷、ドロップフレームの頻発など課題も残りました。またAWS Elemental MediaLiveを使ってライブ配信と同時にアーカイブ出力も行っていましたが、これの迅速な活用についても今後の課題と考えています。
